Basics- Linux Events Logging

In this post we will cover the basics of Event Logging in Linux systems. We will talk about Syslog: Message structure, the most famous implementations and main configurations. We will also play with the inner workings of Linux logging using UNIX sockets, logger and syslog services.

Let’s get to it!

What is Syslog?

Syslog is a standard (RFC5424) used for log management. This management can be local or remote. Do not confuse syslog standard with syslog applications like Syslog-ng, Rsyslog, Nxlog”¦

In some of the most famous Linux distros like Ubuntu, Debian or Fedora, Rsyslog is installed by default. This application can be used for local or remote log management.

Message structure

Syslog message structure is similar to this:

• TIMESTAMP HOSTNAME SERVICE [PID]: MESSAGE

Example:

• <34>Oct 11 22:14:15 mymachine su: ‘su root’ failed for riff on /dev/pts/8

PRI value is calculated using the facility and priority values (see tables and formula below). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Facility values MUST be in the range of 0 to 23 inclusive.

The formula we will use to calculate the PRI is:

• Priority=Facility*8+Severity

This result will be between 0 and 191.

Log storage

We already know the standard syslog message structure. Now, how are these messages managed?

In Linux environments we have a special type of files called “UNIX sockets”. These files are used to transfer information between processes. Processes will read and write data to the socket in order to communicate. In Debian we can list UNIX sockets with the following command:

In our case, applications will write their log messages into this Syslog dedicated socket. Rsyslog service (in Debian/Ubuntu/Fedora) will be “listening” (reading) from this socket. Every new log entry will then be processed according to Rsyslog configuration (later mentioned).

We can send a random message to this socket in order to test our Rsyslog configuration:

Note that you can specify a PRI with the following command: “logger -p kern.err hola”

Rsyslog service

As we have just seen, Rsyslog must be always listening to any log income from syslog UNIX socket. In order to achieve this, Rsyslog service must be always up and running (obviously). You can check its status with the following command:

• Systemctl status Rsyslog.service

One of our main questions is: Which criteria does Rsyslog use to classify and store logs in different files under /var/log? Can this location be modified?

Of course. Rsyslog behaviour is defined in its configuration file and can be easily modified:

• /etc/Rsyslog.d/50-default.conf

This is some of its contents by default:

The storage rules are defined in the first lines following this syntax:

• Facility.severity storage_path

For example, by defining:

• cron.* /var/log/cron.log

All cron facility logs of any severity will be stored under /var/log/cron.log

If we want to send these logs to a remote machine (usually a Log Collector) we will use the following settings (depending on if we want to use TCP or UDP):

• UDP: cron.* @192.168.1.30:514

• TCP: cron.* @@192.168.1.30:514

In general, it is suggested to use TCP syslog since it is way more reliable than UDP. Keep in mind that in case of network congestion, messages might be dropped. We UDP these logs will be lost, but with TCP they will be resend after the network issue. Also note that a TLS option is available in order to send logs, but only with TCP. Nevertheless, TCP is not fully reliable and might also introduce some losses (see this post about TCP reliability). In order to increase reliability, see the RELP protocol from Rsyslog (See below) or the standard RFC3195.

In order to use it, install rsyslog-relp in both client and server (collector). In Debian:

• sudo apt install rsyslog-relp

Then you should add a couple of lines in the config files:

In client:

• module(load=”omrelp”)

• *.* :omrelp:192.168.1.1:4444

In server:

• module(load=”imrelp”)

• input(type=”imrelp” port=”4444″ maxDataSize=”10k”)

Then make sure you restart Rsyslog service in both machines.

• sudo systemctl restart rsyslog

RELP is not part of standard yet and has only been implemented in the following applications:

• librelp – the original C RELP library
• rsyslog (Windows and Linux)
• MonitorWare (Windows)
• logstash

Standard locations under /var/log/

Even though the destination files are fully configurable -as we have just seen-, we will try to maintain some standard names and log files under our /var/log directory:

• Messages (or syslog): General messages. Useful for a first look at logs
• Kern.log: Kernel logs
• Auth.log (or secure): Authorization logs, users’ sessions
• Dmesg: Device driver messages. Use “dmesg” to see its content
• Faillog: Log of failed logins
• Cron: Info related to cron jobs
• Daemon.log: Info about background services (daemons)
• Btmp: Failed login attempts
• Utmp: Current login state by user
• Wtmp: Record of each login/logout
• Lastlog: Record of the last login
• Yum/apt: Logs of package installations
• User.log: Info about all user level logs (coming from user programs)
• Xorg.x.log: Logs about the X (graphic interface)

Log rotation with Rsyslog

Log rotation is the action of saving (usually compressed) old logs for a determined amount of time. In Debian we can achieve this with “logrotate”. This is one of its configuration files (under /etc/logrotate.d/), for Rsyslog it is pretty self-explanatory:

Conclusion

We have seen the basic structure of Syslog messages with its different categories and severities.

Also, we have played with Linux log management and Rsyslog configurations in order to understand its inner workings. In the next post we will introduce Journald, a “new” log manager for Linux. We will see the new features it brings compared to Rsyslog, but also its deficiencies.

Thanks for reading!